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Foreword 



This Technical Specification (TS) has been produced by ECMA on behalf of its members and those of the European 
Telecommunications Standards Institute (ETSI). 



Brief history 



The present document is one of a series of Ecma Standards defining the interworking of services and signalling 
protocols deployed in Corporate telecommunication Networks (CNs) (also known as enterprise networks). The series 
uses telecommunication concepts as developed by ITU-T and conforms to the framework of International Standards on 
Open Systems Interconnection as defined by ISO/IEC. 

The present document specifies call transfer interworking between the Session Initiation Protocol (SIP) and QSIG 
within corporate telecommunication networks (also known as enterprise networks). SIP is an Internet application-layer 
control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These 
sessions include, in particular, telephone calls. 

The present document is based upon the practical experience of Ecma member companies and the results of their active 
and continuous participation in the work of ISO/IEC JTC1, ITU-T, IETF, ETSI and other international and national 
standardization bodies. It represents a pragmatic and widely based consensus. 
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Scope 



The present document specifies call transfer interworking between the Session Initiation Protocol (SIP) and "QSIG" 
within Corporate telecommunication Networks (CN), also known as enterprise networks. 

"QSIG" is a signalling protocol that operates between Private Integrated services Network exchanges (PINX) within a 
Private Integrated Services Network (PISN). A PISN provides circuit-switched basic services and supplementary 
services to its users. QSIG is specified in Ecma Standards, in particular [1] (call control in support of basic services), [2] 
(generic functional protocol for the support of supplementary services) and a number of Standards specifying individual 
supplementary services. Transfer services are specified in [3], [6] and the QSIG signalling protocol in support of these 
services is specified in [4] and [7]. In particular, this signalling protocol signals information about call transfer to the 
users who are involved. 

NOTE: The name QSIG was derived from the fact that it is used for signalling at the Q reference point. The 
Q reference point is a point of demarcation between two PINXs. 

SIP is an application layer protocol for establishing, terminating and modifying multimedia sessions. It is typically 
carried over IP. Telephone calls are considered as a type of multimedia session where just audio is exchanged. SIP is 
defined in [10]. 

As the support of telephony within corporate networks evolves from circuit-switched technology to Internet technology, 
the two technologies will co-exist in many networks for a period, perhaps several years. Therefore there is a need to be 
able to establish, modify, terminate and transfer sessions involving participants in the SIP network and participants in 
the QSIG network. Such calls are supported by gateways that perform interworking between SIP and QSIG. 

The present document specifies SIP -QSIG signalling interworking for transfer services between a PISN employing 
QSIG and a corporate IP network employing SIP. 
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Terminology 



In the present document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in 
RFC 21 19 [9] and indicate requirement levels for compliant SIP implementations. 

In the interests of keeping the normative text and the diagrams as simple as possible, the QSIG messages in the present 
document implicitly follow QSIG signalling rules of [1] and [2], For instance, sending a QSIG DISCONNECT message 
on a call where a QSIG DISCONNECT has already been sent is implicitly forbidden and therefore not mentioned as 
such in the present document. 

The figures in the present document are provided as examples. They are not normative. In the interests of keeping the 
diagrams simple, some SIP messages (ACK, PRACK, final responses to BYE and NOTIFY) are not shown. 

The following notation is used for call transfer information within QSIG messages: 

xxx.inv - invoke application protocol data unit (APDU) of operation xxx. 

xxx.res - return result APDU of operation xxx. 

xxx.err - return error APDU of operation xxx. 
The following abbreviations are used: 

ctActive stands for callTransferActive. 

ctComplete stands for callTransferComplete. 

The drawings use the following conventions: 

Dl and D2 are SIP dialogs. CR1 and CR2 are QSIG call references. By convention, Dl is mapped to CR1 and 
D2 to CR2. 

A SIP message is prefixed by (Dx-y), when it belongs to SIP dialog Dx and is part of SIP transaction y. 

The method or response code of the SIP messages is displayed, as well as the name of SIP header fields that 
play a role in the interworking functions. Some examples display an "Identity:" information field. It indicates 
that the local identity information field should be mapped to a real SIP identity information field as described 
in clause 7.4. 
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4 Definitions 

For the purposes of the present document, the following definitions apply. 

4.1 External definitions 

The definitions in [1] and [10] apply as appropriate. 

4.2 Other definitions 

4.2.1 User A 

The served user, i.e. the user requesting Call transfer or Single step call transfer. 

4.2.2 User B 

A user who is in communication with User A and who will be transferred to User C. 

NOTE: This definitions differs from [3], in order to use similar conventions for QSIG Call transfer and QSIG 
Single step call transfer. 

4.2.3 User C 

The user to whom the call is transferred. 

4.2.4 Call transfer 

The act of enabling a user (User A) to transform two of that user's calls (at least one of which must be answered) into a 
new call between the two other users (User B and User C) in the two calls. 

NOTE: Call transfer is very similar to the "attended transfer" described in [15]. 

A Call transfer before answer is a Call transfer that occurs before User C answers the call initiated by User A. 

4.2.5 Single step call transfer 

The act of enabling a served user (User A) to transfer an active call (with User B) to a user (User C) that has no call 
established either to User A or to User B. On successful completion of Single step call transfer, User B and User C can 
communicate with each other and User A are no longer involved in a call with User B or User C. 

NOTE: Single step call transfer is very similar to the "basic transfer" described in [15]. 



4.2.6 Call transfer by join 



The effecting of transfer when User A is a PISN user by joining together the connections of the calls to User B and User 
C at User A's PINX. 



4.2.7 Call transfer by rerouteing 



The effecting of transfer by establishing a new connection to replace all or part of the connections of the calls to User B 
and User C. 
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4.2.8 Corporate telecommunication Network (CN) 



Sets of privately-owned or carrier-provided equipment that are located at geographically dispersed locations and are 
interconnected to provide telecommunication services to a defined group of users. 

NOTE 1 : A CN can comprise a PISN, a private IP network (intranet) or a combination of the two. 

NOTE 2: Also known as enterprise network. 

4.2.9 IP network 

A network, unless otherwise stated a corporate network, offering connectionless packet-mode services based on the 
Internet Protocol (IP) as the network layer protocol. 

4.2.1 Private Integrated Services Network (PISN) 

A CN or part of a CN that employs circuit-switched technology and QSIG signalling. 

4.2.1 1 Private Integrated services Network exchange (PINX) 

A PISN nodal entity comprising switching and call handling functions and supporting QSIG signalling in accordance 
with [1], 



Abbreviations and acronyms 

APDU Application Protocol Data Unit 

CN Corporate telecommunication Network 

IP Internet Protocol 

ISDN Integrated Services Digital Network 

PINX Private Integrated services Network eXchange 

PISN Private Integrated Services Network 

QSIG Q-ref point SIGnalling 

SIP Session Initiation Protocol 

UA User Agent 

UAC User Agent Client 

UAS User Agent Server 

URI Universal Resource Identifier 



Background and architecture 



The background and architecture of [5] applies. In addition, the interworking function in the protocol model handles 
interworking for call transfer services. This involves interworking between the QSIG call transfer protocol specified in 
[4], [7] and SIP [10], including the use of the REFER [12] SIP method and Replaces [13] and Referred-By [14] SIP 
header fields. 
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7 Procedures 

7.1 Call transfers in QSIG 

For the purposes of QSIG, transfers are classified into one of the following types: 

call transfer by join: defined in clause 4.2.6; 

call transfer by rerouteing: defined in clause 4.2.7; and 

single step call transfer: defined in clause 4.2.5. 

QSIG Call transfer by rerouteing is out of scope of the present document because of its lesser deployment. 

QSIG signalling for transfers is based on [2] and comprises the following remote operations: 

ssctlnitiate - this confirmed operation is sent by User A's PINX to User B's PINX. It initiates a single step call 
transfer. It includes a "rerouteingNumber" of User C. It also includes an optional "transferredAddress" of 
User B, an optional "transferringAddress" of User A, and a optional boolean "awaitConnect" that indicates if 
the operation return result is expected when the call is connected or when it is alerting User C. 

callTransferActive - this unconfirmed operation is sent to User B. It indicates that answer has taken place 
following a Call transfer before answer. It includes a "connectedAddress" that identifies the other User that 
answered the transferred call. 

callTransferComplete - this unconfirmed operation is sent to User B and User C. It indicates that a transfer has 
been effected. It includes an indication of whether the resulting call is alerting or answered (referred to later in 
the present document as "callStatus"). It includes a "redirectionN umber" that identifies the other User in the 
transferred call. 

ssctSetup - this confirmed operation is sent by User B to User C. It initiates a new call between User B and 
User C for the purpose of single step call transfer. It includes an optional "transferringAddress" that indicates 
who initiated the transfer. 

callTransferUpdate - this optional unconfirmed operation is sent to User B and User C. It provides information 
known to the network about the remote party. 

subaddressTransfer - this optional unconfirmed operation is sent to User B or to User C. It informs each other 
of the other party's public ISDN subaddress. It includes a "connectedSubaddress" that identifies the public 
ISDN subaddress. 

7.2 Call transfer in SIP 

SIP has the concept of requesting a UA to refer (establish a dialog to) a third party [12]. SIP also has the concept of 
replacing a dialog by another one [13], and provides a mechanism so that information about the initiator of the REFER 
request is sent to the third party [14]. The call transfer document gives examples on how to support call transfers using 
these SIP extensions [15]. 

7.3 Scope of the interworking functions 
7.3.1 QSIG side 

The interworking functions provided in the following clauses encompass QSIG Call transfer by join and QSIG Single 
step call transfer. QSIG Call transfer by rerouteing is out of scope of the present document because of its lesser 
deployment. The functions take into account that User A, B and C can be in the IP network or in the PISN. 
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7.3.2 SIP side 

The interworking functions rely on SIP mechanisms. Thus, the interworking functions of the present document make 
the following assumptions: 

the gateway and the SIP User Agents use globally routable SIP addresses, or use SIP addresses in an 
environment where they are routable, or will use other future mechanisms that allow global routing; 

it is RECOMMENDED that the gateway and the SIP User Agents use SIP security mechanisms related to 
authentication and confidentiality. 

7.3.3 Discussion over transfer interworking functions 

This clause is not normative and aims at giving explanations concerning the implementation choices of the present 
document. 

The QSIG Single step call transfer mechanism is very similar to the "basic transfer" described in [15]. The QSIG Call 
transfer is also very similar to the "attended transfer" described in [15]. The latter uses the REFER method and the 
Replaces header. Yet, it is not possible to use this mechanism in all the interworking situations. For instance, if User A 
in the PISN does not call User B and User C in the SIP network through the same gateway, there is no opportunity to 
optimize the signalling path by using the REFER method in the IP network. Figure 1 gives an example of such a 
situation where transfer by join has been performed at user A's PINX. The gateway to user B is unaware that user C is 
also in the IP network (and even if it were aware, it has no information for building a Replaces header). Similarly the 
gateway to user C is unaware that user B is in the IP network. 



PISN 



IP Network 



No way to build 
"Replaces: D2" 




E04-0020-A 

Figure 1 : Example of a call transfer by join that involves two gateways 

Of course, an optimization is possible when only one gateway is used, so that the gateway can send a SIP REFER 
request to User B. This optimization is implementation dependant and is out of scope of the present document. 
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When User A and User B or User C are in the PISN, or when the transfer involves two gateways, updating the display 
(name, address, and dialog state of the new remote party) of the SIP User Agents is needed. The solution is based on the 
gateway sending an INVITE request for a new dialog and containing a Replaces header field that matches the existing 
dialog. At present there is no defined way in SIP to transport an updated identity within an existing dialog. How the 
QSIG and SIP fields that indicate identities are derived is described in clause 7.4. 

Another issue is the lack of SIP mechanism to indicate to User B in the IP network that User C in the PISN is being 
alerted. In-band media information (e.g. ringback tone, announcements) may help to inform User B that the call to User 
C is not connected yet. 

Another issue is that the gateway does not always know whether the new call triggered by a single step call transfer 
requested from the PISN must be placed in the IP network or in the PISN. The preferred solution is to reach User C in 
the IP network if the address derivation is possible. Upon failure of address derivation or upon failure of the REFER 
request, the call is placed in the PISN. Figure 2 illustrates this situation. 



PISN 



GATEWAY 



IP Network 



Call Reference CR1 
< ^ 



Dialog D1 



(CR1) FACILITY 
ssctlnitiate.inv 



(DM) REFER 
Refer-To 
Referred-By 



The call is placed in the IP network. 



PISN 



Call Reference CR1 



GATEWAY 



»<- 



IP Network 



Dialog D1 



(CR1) FACILITY 
ssctlnitiate.inv 



(CR2) SETUP 
ssctSetup.inv 



The call is placed in the PISN if the address 
derivation fails or if the REFER request fails. 



E04-0021-A 



Figure 2: Example of call-flows on receipt of a ssctlnitiate invoke APDU 

There is also an ambiguity when a SIP REFER request arrives at a gateway because the gateway might not know if User 
C (the transfer target) is in the PISN or in the IP network. Therefore the gateway does not know whether to issue an 
INVITE request or map the REFER request to a QSIG ssctlnitiate invoke APDU. If there is an embedded Replaces 
header field as a parameter of the Refer-To URI in the REFER request, the gateway knows that User C can be reached 
through the IP network. If there is no Replaces header field, and if the derivation of the Refer-To URI can be done, the 
gateway sends a QSIG ssctlnitiate invoke APDU. If the derivation fails or upon failure of the QSIG ssctlnitiate invoke 
APDU, a SIP INVITE message is sent accordingly to the REFER request. Figure 3 illustrates this situation. 
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IP Network 



Dialog D1 



(DM) REFER 
[no Replaces] 



GATEWAY 



PISN 



On receipt 

Call Reference CR1 of this 
_ x ->User B calls 

UserC 

(CR1) FACILITY 
-> ssctlnitiate.inv 



This call flow occurs if address derivation succeeds. 
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x > 



(D-1) REFER 
[no Replaces] 



(D2-1) INVITE 



The call flow occurs if the previous one fails. 

E04-0022-A 

Figure 3: Example of call-flows on receipt of a REFER request 

A Call transfer before answer cannot be implemented with a Replaces header field, because Replaces cannot match an 
early dialog at the UAS. Therefore "attended transfer" as defined in [15] cannot happen until User C answers the call. 
That document suggests that "unattended transfer" be used if attended transfer cannot be done. 



7.4 Mapping of numbers and URIs 



Most of the interworking functions require the mapping of identifiers, e.g., the identifier User A, User B and User C. In 
QSIG users are identified by numbers. In SIP users are identified by URIs. Mapping of identifiers is described in detail 
in [8]. 

In some cases it may not be possible for a gateway to map a SIP URI to a QSIG number or vice versa. If it is not 
possible to derive an identifier that is essential for generating a signalling element relating to transfer, unless otherwise 
stated the call should be allowed to continue without that signalling element. In that case, the gateway should use a 
QSIG indication that the number is not provided for interoperability reasons. 

The identity of the remote party must be derived as described in clauses 9. 1 and 9.2 of [5], 

Clause 9 defines how to proceed in case of privacy or trust issues. 
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7.5 UAC Processing 

7.5.1 Receipt of a FACILITY message with callTransferComplete invoke 
APDU 

On receipt of a QSIG FACILITY message that contains a callTransferComplete invoke APDU (as a result of transfer by 
join in the QSIG network), the gateway SHALL send a SIP INVITE request that initiates a new dialog to replace the 
existing one. The gateway SHALL use the redirectionNumber element of the callTransferComplete invoke APDU to 
generate identity information in the SIP INVITE request in the same way that a QSIG Calling party number information 
element is used to generate identity information in a SIP INVITE request when establishing a new call from QSIG to 
SIP, as specified in [5]. The INVITE request SHALL use a Replaces header [13] to indicate which dialog is replaced. 
The INVITE request SHOULD use the Referred-By header [14] to indicate the identity of the Referrer and the gateway 
SHOULD copy the local URI of the replaced dialog into the Referred-By header field. 



PISN 



GATEWAY IP Network 



Call Reference CR1 Dialog D1 
< >< 

(CR1) FACILITY <° 2 > ™™ 
ctComplete.inv Heierrea by 
> Replaces D1 

(D2)20Q OK 
(D1)BYE 



E04-0023-A 

Figure 4: Example of message flows on receipt of a FACILITY 

On receipt of an error final response to the INVITE request, no QSIG message is sent. There is no way for the gateway 
to notify the PINX that the transfer could not be indicated to the user in the SIP network. 

If the URI of the identity information field in the SIP request cannot be derived from the QSIG number, the gateway 
SHALL take no action. 

7.5.2 Receipt of a FACILITY message with callTransferUpdate invoke 
APDU 

On receipt of a QSIG FACILITY message that contains a callTransferUpdate invoke APDU (as a result of the identity 
of the remote party being updated in the QSIG network), the gateway SHALL look up the optional redirectionNumber. 
If the information updates the previous settings, the gateway SHALL act as if it received a callTransferComplete invoke 
APDU (see clause 7.5.1). 

7.5.3 Receipt of a FACILITY message with ssctlnitiate invoke APDU 

On receipt of a QSIG FACILITY message that contains a ssctlnitiate invoke APDU (as a result of a single step call 
transfer request in the QSIG network), the gateway SHALL send a SIP REFER request inside the current dialog as 
described in [12]. The URI in the Refer-To header field SHALL be derived from the rerouteingNumber of the 
ssctlnitiate invoke APDU. The REFER request SHOULD use [14] to indicate the identity of the transferor and derive 
the URI in the Referred-By header field from the transferringAddress of the ssctlnitiate invoke APDU. 
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On receipt of a SIP NOTIFY request indicating: 

a provisional alerting response, the gateway SHOULD send a QSIG FACILITY message that contains a 
ssctlnitiate return result APDU if the awaitConnect boolean value in the invoke APDU is FALSE; 

a successful final response, the gateway SHALL send a FACILITY message with the ssctlnitiate return result 
APDU if no ssctlnitiate return result or return error APDU has already been sent; 

an error final response, the gateway SHALL send a FACILITY message with a ssctlnitiate return error APDU, 
unless a ssctlnitiate return result has already been sent. 



PISN 



GATEWAY 



IP Network 



Call Reference CR1 



»<- 



Dialog D1 



(CR1) FACILITY 
ssctlnitiate. inv 



(CR1) FACILITY 
ssctlnitiate.res 



(CR1) RELEASE 
(CR1) RELEASE CPLT 



(D1-1) REFER 
Refer-To 
Referred-By 



(D1 -1)202 ACCEPTED 



(D1 -2) NOTIFY (200 OK) 



(D1-3)BYE 



E04-0024-A 

Figure 5: Example of message flows on receipt of a FACILITY message with ssctlnitiate invoke APDU 

If the URI in the Refer-To header field cannot be derived, the gateway SHALL send a FACILITY message that 
contains a ssctlnitiate return error APDU. 



7.5.4 



Receipt of a SETUP message with ssctSetup invoke APDU 

a OSIG SETUP messase that contains a ssctSetun invoke APDU (as a result of sinele sten ca 



On receipt of a QSIG SETUP message that contains a ssctSetup invoke APDU (as a result of single step call transfer in 
the QSIG network), the gateway SHALL send a SIP INVITE that initiates a new dialog with the transfer target. The 
INVITE request SHALL be generated in accordance with [5], In addition, it SHOULD use [14] to indicate the identity 
of the transferor and derive the URI in the Referred-By header field from the transferringAddress of the ssctSetup 
invoke APDU. 

On receipt of responses to the INVITE request, the gateway SHALL act as described in [5]. 
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Figure 6: Example of message flows on receipt of a SETUP message with ssctSetup invoke APDU 

7.5.5 Receipt of a FACILITY message with subaddressTransfer invoke 
APDU 

On receipt of a QSIG FACILITY message that contains a subaddressTransfer invoke APDU (as a result of the remote 
party being in the public ISDN and having a subaddress), the gateway MAY derive a SIP or tel URI from the 
connectedSubaddress and act as if it received a callTransferComplete invoke APDU (see clause 7.5.1). 

7.6 UAS Processing 

7.6.1 Receipt of a SIP REFER request 

On receipt of a SIP REFER request that is inside a dialog, the gateway can act in various ways depending on the 
contents of the Refer-To header field. Only Refer-To URIs with a method = INVITE parameter are in the scope of the 
present document. 

In this clause, an embedded Replaces header is a Replaces header field as a parameter of a Refer-To URI. 



7.6.1.1 



No embedded Replaces header field in the Refer-To URI 



On receipt of a SIP REFER request that is inside a dialog and that has no embedded Replaces header field in the 
Refer-To URI, the gateway SHALL accept the REFER request. 

If the gateway is able to derive a RerouteingNumber from the Refer-To URI, the gateway SHALL send a QSIG 
FACILITY message that contains a ssctlnitiate invoke APDU. The gateway SHOULD derive the transferringAddress of 
the ssctlnitiate invoke APDU from the Referred-By header field if present. The gateway SHOULD derive the 
transferredAddress from the identity of the local PISN user in the existing dialog. The gateway SHALL include value 
TRUE in the awaitConnect element. 

On receipt of a QSIG FACILITY message that includes a ssctlnitiate return result APDU, the gateway SHALL send a 
SIP NOTIFY request as described in [12]. The final status in the NOTIFY body is "200 OK". 
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Figure 7: Example of message flows on receipt of a SIP REFER request (no Replaces header) 

If the derivation of the rerouteingNumber fails, or upon reception of a QSIG FACILITY message that includes a 
ssctlnitiate return error APDU, the gateway SHALL send a SIP INVITE message as described in [12] and in [13]. The 
gateway SHALL then comply with [12] and [13] and send SIP NOTIFY messages that indicate the result of the 
INVITE transaction. 

On receipt of a " 180 RINGING" provisional response to the INVITE request, the gateway SHOULD send a QSIG 
FACILITY message that contains a callTransferComplete invoke APDU with a callStatus of "alerting". 

On receipt of a successful final response to the INVITE request, the gateway SHALL send a QSIG FACILITY message 
that contains: 

a callTransferActive invoke APDU, if a callTransferComplete invoke APDU has already been sent; or 

a callTransferComplete invoke APDU with a callStatus of "answered". 

The gateway SHALL derive the redirectionNumber of the callTransferComplete invoke APDU and the 
connectedAddress of the callTransferActive invoke APDU from the identity information representing the called party 
transported in the responses to the INVITE request, or from the URI in the Refer-To header field if no identity 
information is available. If the derivation fails, the gateway SHALL signal that numbers and addresses are not available 
due to interworking issues. 

On receipt of an error final response to the INVITE request and if a callTransferComplete invoke APDU was invoked 
before, the gateway SHOULD send a FACILITY message that contains a callTransferActive invoke APDU. It indicates 
that the QSIG call between transferor and transferee is active again. 
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Figure 8: Example of message flows on receipt of a SIP REFER request (no Replaces header) 

when address derivation fails 



7.6.1.2 



Matching embedded Replaces header in the Refer-To URI 



On receipt of a SIP REFER request that is inside a dialog and that has an embedded Replaces header field in the 
Refer-To URI, the gateway SHALL determine whether the Refer-To URI identifies the gateway. If it does not identify 
the gateway, the gateway SHALL act as described in clause 7.6.1.3. 

If the Refer-To URI identifies the gateway, the gateway SHALL accept the REFER request and look up its internal list 
of SIP dialogs. If one of the dialogs matches the Replaces header field contents as described in [13], the gateway 
SHALL send a QSIG FACILITY message that contains a callTransferComplete invoke APDU with the QSIG call 
reference that maps to the SIP dialog of the REFER message. The gateway SHALL copy the number of the PISN party 
of the matched dialog to the redirectionNumber of the callTransferComplete invoke APDU. 

If the matching dialog is: 

not established then the callStatus of the callTransferComplete invoke APDU SHALL be "alerting", and the 
gateway SHALL send a SIP NOTIFY request with a body that indicates the latest provisional response code 
sent on the matching dialog; 

established then the callStatus of the callTransferComplete invoke APDU SHALL be "answered", and the 
gateway SHALL send a NOTIFY request with a body that indicates "200 OK". 

The gateway SHALL also send a FACILITY message that contains a callTransferComplete invoke APDU with the 
QSIG call reference that maps the matching SIP dialog. The gateway SHALL derive the redirectionNumber of the 
callTransferComplete invoke APDU from the number of the PISN party in the dialog to which the REFER request 
belongs. The gateway SHALL include value "answered" in the callStatus element. The gateway SHALL join the two 
QSIG calls together and act as a transit PINX as defined in [1]. 

The gateway MAY then release the two SIP dialogs. 
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Figure 9: Example of message flows on receipt of a SIP REFER request 
(matching Replaces header field) 



7.6.1.3 



Non-matching embedded Replaces header in the Refer-To URI 



If the Refer-To URI identifies the gateway but none of the internal list of dialogs matches the Replaces header field 
contents as described in [13], the gateway SHALL reject the REFER request with a SIP response code of "502 Bad 
Gateway". 
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Figure 10: Example of message flows on receipt of a SIP REFER request 
(rejection on non-matching Replaces header field) 



If the Refer-To URI does not identify the gateway, the gateway SHALL accept the REFER request and send a SIP 
INVITE message as described in [12] and [13]. The gateway SHALL then comply with [12] and [13] and send SIP 
NOTIFY messages that indicate the result of the INVITE transaction. 
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On receipt of a " 180 RINGING" provisional response to the INVITE request, the gateway SHOULD send a QSIG 
FACILITY message that contains a callTransferComplete invoke APDU with a callStatus of "alerting". The FACILITY 
message SHALL be sent with the QSIG call reference that maps to the SIP dialog of the REFER message. 

On receipt of a successful final response to the INVITE request, the gateway SHALL send a QSIG FACILITY message 
that contains: 

a callTransferActive invoke APDU, if a callTransferComplete invoke APDU has already been sent; or 

a callTransferComplete invoke APDU with a callStatus of "answered". 

The FACILITY message SHALL be sent with the QSIG call reference that maps to the SIP dialog of the REFER 

message. 

The gateway SHALL derive the redirectionNumber of the callTransferComplete invoke APDU and the 
connectedAddress of the callTransferActive invoke APDU from the URI in the Refer-To header field or from other 
identity information representing the SIP called party transported in the responses to the INVITE request. 

On receipt of an error final response to the INVITE request and if a callTransferComplete invoke APDU was invoked 
before, the gateway SHOULD send a FACILITY message that contains a callTransferActive invoke APDU. It indicates 
that the QSIG call between transferor and transferee is active again. 
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Figure 1 1 : Example of message flows on receipt of a SIP REFER request 
(accept non-matching Replaces header field) 



ETSI 



21 



ETSI TS 102 392 V1 .1 .1 (2005-02) 



7.6.2 Receipt of a SIP INVITE request 



7.6.2.1 



Receipt of an INVITE with no Replaces header 



On receipt of a SIP INVITE request that is outside a dialog and that has no Replaces header, the gateway SHALL send 
a QSIG SETUP message as described in [5]. If the INVITE request includes a Referred-By header field, the QSIG 
SETUP message SHOULD contain a ssctSetup invoke APDU with a transferringAddress derived from the Referred-By 
header described in [14]. 
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Figure 12: Example of message flows on receipt of a SIP INVITE request (no Replaces header) 



7.6.2.2 



Receipt of an INVITE with a Replaces header 



On receipt of a SIP INVITE request that is outside a dialog and that has a matching Replaces header field [13], the 
gateway SHALL send a QSIG FACILITY message that contains a callTransferComplete invoke APDU. The 
FACILITY message is sent with the QSIG call reference that maps to the SIP dialog matched against the Replaces 
header field. The redirectionNumber in the callTransferComplete invoke APDU SHALL be derived from the SIP URI 
representing the calling party as described in clause 9.2.2 of [5]. 
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Figure 13: Example of message flows on receipt of a SIP INVITE request 
(matching Replaces header field) 

If the Replaces header field does not match, the gateway SHALL reject the INVITE request as described in [13]. Note 
that this may happen if two different gateways can be used to reach the QSIG side. 
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7.6.3 Receipt of a SIP request with revised identity 

On receipt of a SIP request (for instance, UPDATE or INVITE) that is within a dialog and that transports a revised 
identity, the gateway MAY send a QSIG FACILITY message that contains a callTransferComplete invoke APDU. The 
FACILITY message is sent with the QSIG call reference that maps to the SIP dialog. The redirectionNumber in the 
callTransferComplete invoke APDU SHALL be derived from the revised identity. 



8 Example message sequences 

8.1 Call transfer by join where User B and C are SIP 
participants 
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NOTE: If Gateway 1 and Gateway 2 are the same gateway, some implementation dependant optimization 
mechanisms using a SIP REFER request may take place. 

Figure 14: Example of Call transfer by join where User B and User C are SIP participants 
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8.2 Call transfer where User A is a SIP participant 
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Figure 15: Example of Call transfer where User A is a SIP participant and where one gateway is used 
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8.3 Call transfer where User A is a SIP participant and where 
two gateways are used 
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Figure 16: Example of Call transfer where User A is a SIP participant and where 

two gateways are used 
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8.4 Call transfer where User A and User B are SIP participants 



A 

(SIP) 



<- 
<- 



<r 



£- 



Dialog D1 



B 

(SIP) 

-> 



Gateway 
1 



C 
(QSIG) 



Dialog D2 



(D1-1) REFER 

Refer-To: 

C; Replaces :D2 



-> 



(D1 -1)202 

(D1 -2) NOTIFY 
100 



-» 



■C- 



(D1-2)200 OK 

(D1 -3) NOTIFY 
200 

(D1-3)200 OK 



-» 



Call Ref CR2 
>k > 



(D1-4)BYE 
(D1-4)200 OK 



-* 



(D3-1) INVITE 
Replaces: D2 



(D3-1)200 OK 
< 



(D3-2) ACK 



(D2-1)BYE 



^ 



■}■ 



(D2-1)200 OK 



* match * 
(CR2) FACILITY 
ctComplete.inv 



> 



7.6.2.2 



E04-0036-A 



Figure 17: Example of Call transfer where User A and User B are SIP participants 
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8.5 Single step call transfer where User B is a SIP participant 
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Figure 18: Example of a Single step call transfer where User B is a SIP participant 
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8.6 Unsuccessful Single step call transfer where User A and 
User C are SIP participants 
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Figure 19: Example of an unsuccessful Single step call transfer where 
User A and User C are SIP participants 
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8.7 Single step call transfer where User A and User B are SIP 
participants 
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Figure 20: Example of a Single step call transfer where User A and User B are SIP participants 



Security considerations 



The security considerations related to the SIP mechanisms used in the present document apply. 

The security considerations related to the derivation of address and identity between SIP and QSIG described in [5] 
apply. 

The security considerations due to the transfer interworking functions between QSIG and SIP are related to the 
derivation of the identity of User A, User B and User C. 

If identity information issued by the IP network is not trusted, the gateway SHOULD not derive the transferredAddress, 
transferringAddress and redirectionNumber of the QSIG invoke APDUs from the SIP header fields. It SHOULD 
indicate that the numbers are not available due to interworking. 

If identity information issued by the IP network is not to be disclosed for privacy reasons, as indicated in the Privacy 
header [11], the gateway SHALL not derive the transferredAddress, transferringAddress and redirectionNumber of the 
QSIG invoke APDUs from the SIP header fields, unless the targeted PINX is in the same domain, in which case the 
gateway SHALL indicate that the numbers are not available due to screening. If the targeted PINX is in the same 
domain and the Privacy header defined in [11] is used, the gateway MAY derive the identity information and SHALL 
indicate that the presentation is restricted. 

If identity information issued by the PISN is not to be disclosed because of local policy or PISN privacy requests, the 
gateway SHALL not derive SIP header field URIs from the transferredAddress, transferringAddress and 
redirectionNumber of the QSIG invoke APDUs, unless the targeted SIP entity is in the same domain, in which case the 
information MAY be disclosed in conjunction with the Privacy header defined in [11]. 
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